home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1006.txt < prev    next >
Text File  |  1994-08-01  |  29KB  |  1,008 lines
  1.  
  2.  
  3. Network Working Group                    Marshall T. Rose, Dwight E. Cass
  4. Request for Comments: RFC 1006    Northrop Research and Technology Center
  5.                                                                  May 1987
  6.  
  7.  
  8.  
  9.                 ISO Transport Services on top of the TCP
  10.                                Version: 3
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This memo specifies a standard for the Internet community. Hosts
  17.    on the Internet that choose to implement ISO transport services
  18.    on top of the TCP are expected to adopt and implement this
  19.    standard.  TCP port 102 is reserved for hosts which implement this
  20.    standard.  Distribution of this memo is unlimited.
  21.  
  22.    This memo specifies version 3 of the protocol and supersedes
  23.    [RFC983].  Changes between the protocol as described in Request for
  24.    Comments 983 and this memo are minor, but are unfortunately
  25.    incompatible.
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. M. Rose & D. Cass                                               [Page 1]
  63.  
  64. RFC 1006                                                        May 1987
  65.  
  66.  
  67. 1.  Introduction and Philosophy
  68.  
  69.  
  70.       The Internet community has a well-developed, mature set of
  71.       transport and internetwork protocols (TCP/IP), which are quite
  72.       successful in offering network and transport services to
  73.       end-users. The CCITT and the ISO have defined various session,
  74.       presentation, and application recommendations which have been
  75.       adopted by the international community and numerous vendors.
  76.       To the largest extent possible, it is desirable to offer these
  77.       higher level directly in the ARPA Internet, without disrupting
  78.       existing facilities.  This permits users to develop expertise
  79.       with ISO and CITT applications which previously were not
  80.       available in the ARPA Internet.  It also permits a more
  81.       graceful convergence and transition strategy from
  82.       TCP/IP-based networks to ISO-based networks in the
  83.       medium-and long-term.
  84.  
  85.       There are two basic approaches which can be taken when "porting"
  86.       an ISO or CCITT application to a TCP/IP environment.  One
  87.       approach is to port each individual application separately,
  88.       developing local protocols on top of the TCP.  Although this is
  89.       useful in the short-term (since special-purpose interfaces to the
  90.       TCP can be developed quickly), it lacks generality.
  91.  
  92.       A second approach is based on the observation that both the ARPA
  93.       Internet protocol suite and the ISO protocol suite are both
  94.       layered systems (though the former uses layering from a more
  95.       pragmatic perspective).  A key aspect of the layering principle
  96.       is that of layer-independence.  Although this section is
  97.       redundant for most readers, a slight bit of background material
  98.       is necessary to introduce this concept.
  99.  
  100.       Externally, a layer is defined by two definitions:
  101.  
  102.          a service-offered definition, which describes the services
  103.          provided by the layer and the interfaces it provides to
  104.          access those services; and,
  105.  
  106.          a service-required definitions, which describes the services
  107.          used by the layer and the interfaces it uses to access those
  108.          services.
  109.  
  110.       Collectively, all of the entities in the network which co-operate
  111.       to provide the service are known as the service-provider.
  112.       Individually, each of these entities is known as a service-peer.
  113.  
  114.       Interally, a layer is defined by one definition:
  115.  
  116.           a protocol definition, which describes the rules which each
  117.           service-peer uses when communicating with other service-peers.
  118.  
  119.  
  120.  
  121. M. Rose & D. Cass                                               [Page 2]
  122.  
  123. RFC 1006                                                        May 1987
  124.  
  125.  
  126.       Putting all this together, the service-provider uses the protocol
  127.       and services from the layer below to offer the its service to the
  128.       layer above.  Protocol verification, for instance, deals with
  129.       proving that this in fact happens (and is also a fertile field
  130.       for many Ph.D. dissertations in computer science).
  131.  
  132.       The concept of layer-independence quite simply is:
  133.  
  134.           IF one preserves the services offered by the service-provider
  135.  
  136.           THEN the service-user is completely naive with respect to the
  137.           protocol which the service-peers use
  138.  
  139.  
  140.       For the purposes of this memo, we will use the layer-independence
  141.       to define a Transport Service Access Point (TSAP) which appears
  142.       to be identical to the services and interfaces offered by the
  143.       ISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact
  144.       implement theISO TP0 protocol on top of TCP/IP (as defined in
  145.       [RFC793,RFC791]), not on top of the the ISO/CCITT network
  146.       protocol.  Since the transport class 0 protocol is used over the
  147.       TCP/IP connection, it achieves identical functionality as
  148.       transport class 4.  Hence, ISO/CCITT higher level layers (all
  149.       session, presentation, and application entities) can operate
  150.       fully without knowledge of the fact that they are running on a
  151.       TCP/IP internetwork.
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180. M. Rose & D. Cass                                               [Page 3]
  181.  
  182. RFC 1006                                                        May 1987
  183.  
  184.  
  185. 2.  Motivation
  186.  
  187.  
  188.       In migrating from the use of TCP/IP to the ISO protocols, there
  189.       are several strategies that one might undertake.  This memo was
  190.       written with one particular strategy in mind.
  191.  
  192.       The particular migration strategy which this memo uses is based
  193.       on the notion of gatewaying between the TCP/IP and ISO ptotocol
  194.       suites at the transport layer.  There are two strong arguments
  195.       for this approach:
  196.  
  197.       1.  Experience teaches us that it takes just as long to get good
  198.       implementations of the lower level protocols as it takes to get
  199.       implementations of the higher level ones.  In particular, it has
  200.       been observed that there is still a lot of work being done at the
  201.       ISO network and transport layers.  As a result, implementations
  202.       of protocols above these layers are not being aggressively
  203.       pursued. Thus, something must be done "now" to provide a medium
  204.       in which the higher level protocols can be developed.  Since
  205.       TCP/IP is mature, and essentially provides identical
  206.       functionality, it is an ideal medium to support this development.
  207.  
  208.       2.  Implementation of gateways at the IP and ISO IP layers are
  209.       probably not of general use in the long term.  In effect, this
  210.       would require each Internet host to support both TP4 and TCP.
  211.       As such, a better strategy is to implement a graceful migration
  212.       path from TCP/IP to ISO protocols for the ARPA Internet when the
  213.       ISO protocols have matured sufficiently.
  214.  
  215.       Both of these arguments indicate that gatewaying should occur at
  216.       or above the transport layer service access point.  Further, the
  217.       first argument suggests that the best approach is to perform the
  218.       gatewaying exactly AT the transport service access point to
  219.       maximize the number of ISO layers which can be developed.
  220.  
  221.         NOTE:     This memo does not intend to act as a migration or
  222.                   intercept document.  It is intended ONLY to meet the
  223.                   needs discussed above.  However, it would not be
  224.                   unexpected that the protocol described in this memo
  225.                   might form part of an overall transition plan.  The
  226.                   description of such a plan however is COMPLETELY
  227.                   beyond the scope of this memo.
  228.  
  229.       Finally, in general, building gateways between other layers in the
  230.       TCP/IP and ISO protocol suites is problematic, at best.
  231.  
  232.       To summarize: the primary motivation for the standard described in
  233.       this memo is to facilitate the process of gaining experience with
  234.       higher-level ISO protocols (session, presentation, and
  235.       application). The stability and maturity of TCP/IP are ideal for
  236.  
  237.  
  238.  
  239. M. Rose & D. Cass                                               [Page 4]
  240.  
  241. RFC 1006                                                        May 1987
  242.  
  243.  
  244.       providing solid transport services independent of actual
  245.       implementation.
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298. M. Rose & D. Cass                                               [Page 5]
  299.  
  300. RFC 1006                                                        May 1987
  301.  
  302.  
  303. 3.  The Model
  304.  
  305.  
  306.       The [ISO8072] standard describes the ISO transport service
  307.       definition, henceforth called TP.
  308.  
  309.           ASIDE:    This memo references the ISO specifications rather
  310.                     than the CCITT recommendations.  The differences
  311.                     between these parallel standards are quite small,
  312.                     and can be ignored, with respect to this memo,
  313.                     without loss of generality.  To provide the reader
  314.                     with the relationships:
  315.  
  316.                          Transport service    [ISO8072]       [X.214]
  317.                          Transport protocol   [ISO8073]       [X.224]
  318.                          Session protocol     [ISO8327]       [X.225]
  319.  
  320.  
  321.       The ISO transport service definition describes the services
  322.       offered by the TS-provider (transport service) and the interfaces
  323.       used to access those services.  This memo focuses on how the ARPA
  324.       Transmission Control Protocol (TCP) [RFC793] can be used to offer
  325.       the services and provide the interfaces.
  326.  
  327.  
  328.       +-----------+                                       +-----------+
  329.       |  TS-user  |                                       |  TS-user  |
  330.       +-----------+                                       +-----------+
  331.            |                                                     |
  332.            | TSAP interface                       TSAP interface |
  333.            |  [ISO8072]                                          |
  334.            |                                                     |
  335.       +----------+   ISO Transport Services on the TCP     +----------+
  336.       |  client  |-----------------------------------------|  server  |
  337.       +----------+              (this memo)                +----------+
  338.            |                                                     |
  339.            | TCP interface                         TCP interface |
  340.            |  [RFC793]                                           |
  341.            |                                                     |
  342.  
  343.  
  344.       For expository purposes, the following abbreviations are used:
  345.  
  346.          TS-peer      a process which implements the protocol described
  347.                       by this memo
  348.  
  349.          TS-user      a process talking using the services of a TS-peer
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357. M. Rose & D. Cass                                               [Page 6]
  358.  
  359. RFC 1006                                                        May 1987
  360.  
  361.  
  362.          TS-provider  the black-box entity implementing the protocol
  363.                       described by this memo
  364.  
  365.  
  366.       For the purposes of this memo, which describes version 2 of the
  367.       TSAP protocol, all aspects of [ISO8072] are supported with one
  368.       exception:
  369.  
  370.           Quality of Service parameters
  371.  
  372.  
  373.       In the spirit of CCITT, this is left "for further study".  A
  374.       future version of the protocol will most likely support the QOS
  375.       parameters for TP by mapping these onto various TCP parameters.
  376.  
  377.       The ISO standards do not specify the format of a session port
  378.       (termed a TSAP ID).  This memo mandates the use of the GOSIP
  379.       specification [GOSIP86] for the interpretation of this field.
  380.       (Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".)
  381.  
  382.       Finally, the ISO TSAP is fundamentally symmetric in behavior.
  383.       There is no underlying client/server model.  Instead of a server
  384.       listening on a well-known port, when a connection is established,
  385.       the TS-provider generates an INDICATION event which, presumably
  386.       the TS-user catches and acts upon.  Although this might be
  387.       implemented by having a server "listen" by hanging on the
  388.       INDICATION event, from the perspective of the ISO TSAP, all TS-
  389.       users just sit around in the IDLE state until they either generate
  390.       a REQUEST or accept an INDICATION.
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416. M. Rose & D. Cass                                               [Page 7]
  417.  
  418. RFC 1006                                                        May 1987
  419.  
  420.  
  421. 4.  The Primitives
  422.  
  423.  
  424.       The protocol assumes that the TCP[RFC793] offers the following
  425.       service primitives:
  426.  
  427.                                     Events
  428.  
  429.          connected       - open succeeded (either ACTIVE or PASSIVE)
  430.  
  431.          connect fails   - ACTIVE open failed
  432.  
  433.          data ready      - data can be read from the connection
  434.  
  435.          errored         - the connection has errored and is now closed
  436.  
  437.          closed          - an orderly disconnection has started
  438.  
  439.                                      Actions
  440.  
  441.          listen on port  - PASSIVE open on the given port
  442.  
  443.          open port       - ACTIVE open to the given port
  444.  
  445.          read data       - data is read from the connection
  446.  
  447.          send data       - data is sent on the connection
  448.  
  449.          close           - the connection is closed (pending data is
  450.                            sent)
  451.  
  452.  
  453. This memo describes how to use these services to emulate the following
  454. service primitives, which are required by [ISO8073]:
  455.  
  456.                                  Events
  457.  
  458.          N-CONNECT.INDICATION
  459.                           - An NS-user (responder) is notified that
  460.                             connection establishment is in progress
  461.  
  462.  
  463.          N-CONNECT.CONFIRMATION
  464.                           - An NS-user (responder) is notified that
  465.                             the connection has been established
  466.  
  467.          N-DATA.INDICATION
  468.                           - An NS-user is notified that data can be
  469.                             read from the connection
  470.  
  471.  
  472.  
  473.  
  474.  
  475. M. Rose & D. Cass                                               [Page 8]
  476.  
  477. RFC 1006                                                        May 1987
  478.  
  479.  
  480.          N-DISCONNECT.INDICATION
  481.                           - An NS-user is notified that the connection
  482.                             is closed
  483.  
  484.                                 Actions
  485.  
  486.          N-CONNECT.REQUEST
  487.                           - An NS-user (initiator) indicates that it
  488.                             wants to establish a connection
  489.  
  490.          N-CONNECT.RESPONSE
  491.                           - An NS-user (responder) indicates that it
  492.                             will honor the request
  493.  
  494.          N-DATA.REQUEST   - An NS-user sends data
  495.  
  496.          N-DISCONNECT.REQUEST
  497.                           - An NS-user indicates that the connection
  498.                             is to be closed
  499.  
  500.       The protocol offers the following service primitives, as defined
  501.       in [ISO8072], to the TS-user:
  502.  
  503.                                     Events
  504.  
  505.          T-CONNECT.INDICATION
  506.                           - a TS-user (responder) is notified that
  507.                             connection establishment is in progress
  508.  
  509.          T-CONNECT.CONFIRMATION
  510.                           - a TS-user (initiator) is notified that the
  511.                             connection has been established
  512.  
  513.          T-DATA.INDICATION
  514.                           - a TS-user is notified that data can be read
  515.                             from the connection
  516.  
  517.          T-EXPEDITED DATA.INDICATION
  518.                           - a TS-user is notified that "expedited" data
  519.                             can be read from the connection
  520.  
  521.          T-DISCONNECT.INDICATION
  522.                           - a TS-user is notified that the connection
  523.                             is closed
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534. M. Rose & D. Cass                                               [Page 9]
  535.  
  536. RFC 1006                                                        May 1987
  537.  
  538.  
  539.                                 Actions
  540.  
  541.          T-CONNECT.REQUEST
  542.                           - a TS-user (initiator) indicates that it
  543.                             wants to establish a connection
  544.  
  545.          T-CONNECT.RESPONSE
  546.                           - a TS-user (responder) indicates that it
  547.                             will honor the request
  548.  
  549.          T-DATA.REQUEST   - a TS-user sends data
  550.  
  551.          T-EXPEDITED DATA.REQUEST
  552.                           - a TS-user sends "expedited" data
  553.  
  554.          T-DISCONNECT.REQUEST
  555.                           - a TS-user indicates that the connection
  556.                             is to be closed
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593. M. Rose & D. Cass                                              [Page 10]
  594.  
  595. RFC 1006                                                        May 1987
  596.  
  597.  
  598. 5.  The Protocol
  599.  
  600.  
  601.       The protocol specified by this memo is identical to the protocol
  602.       for ISO transport class 0, with the following exceptions:
  603.  
  604.             - for testing purposes, initial data may be exchanged
  605.               during connection establishment
  606.  
  607.             - for testing purposes, an expedited data service is
  608.               supported
  609.  
  610.             - for performance reasons, a much larger TSDU size is
  611.               supported
  612.  
  613.             - the network service used by the protocol is provided
  614.               by the TCP
  615.  
  616.  
  617.       The ISO transport protocol exchanges information between peers in
  618.       discrete units of information called transport protocol data units
  619.       (TPDUs).  The protocol defined in this memo encapsulates these
  620.       TPDUs in discrete units called TPKTs.  The structure of these
  621.       TPKTs and their relationship to TPDUs are discussed in the next
  622.       section.
  623.  
  624.       PRIMITIVES
  625.  
  626.          The mapping between the TCP service primitives and the service
  627.          primitives expected by transport class 0 are quite straight-
  628.          forward:
  629.  
  630.                    network service              TCP
  631.                    ---------------              ---
  632.                    CONNECTION ESTABLISHMENT
  633.  
  634.                        N-CONNECT.REQUEST        open completes
  635.  
  636.                        N-CONNECT.INDICATION     listen (PASSIVE open)
  637.                                                 finishes
  638.  
  639.                        N-CONNECT.RESPONSE       listen completes
  640.  
  641.                        N-CONNECT.CONFIRMATION   open (ACTIVE open)
  642.                                                 finishes
  643.  
  644.                    DATA TRANSFER
  645.  
  646.                        N-DATA.REQUEST           send data
  647.  
  648.                        N-DATA.INDICATION        data ready followed by
  649.  
  650.  
  651.  
  652. M. Rose & D. Cass                                              [Page 11]
  653.  
  654. RFC 1006                                                        May 1987
  655.  
  656.  
  657.                                                 read data
  658.  
  659.                    CONNECTION RELEASE
  660.  
  661.                        N-DISCONNECT.REQUEST     close
  662.  
  663.                        N-DISCONNECT.INDICATION  connection closes or
  664.                                                 errors
  665.  
  666.           Mapping parameters is also straight-forward:
  667.  
  668.                      network service             TCP
  669.                      ---------------             ---
  670.                      CONNECTION RELEASE
  671.  
  672.                          Called address          server's IP address
  673.                                                  (4 octets)
  674.  
  675.                          Calling address         client's IP address
  676.                                                  (4 octets)
  677.  
  678.                          all others              ignored
  679.  
  680.                       DATA TRANSFER
  681.  
  682.                          NS-user data (NSDU)     data
  683.  
  684.                       CONNECTION RELEASE
  685.  
  686.                          all parameters          ignored
  687.  
  688.  
  689.  
  690.       CONNECTION ESTABLISHMENT
  691.  
  692.           The elements of procedure used during connection establishment
  693.           are identical to those presented in [ISO8073], with three
  694.           exceptions.
  695.  
  696.           In order to facilitate testing, the connection request and
  697.           connection confirmation TPDUs may exchange initial user data,
  698.           using the user data fields of these TPDUs.
  699.  
  700.           In order to experiment with expedited data services, the
  701.           connection request and connection confirmation TPDUs may
  702.           negotiate the use of expedited data transfer using the
  703.           negotiation mechanism specified in [ISO8073] is used (e.g.,
  704.           setting the "use of transport expedited data transfer service"
  705.           bit in the "Additional Option Selection" variable part). The
  706.           default is not to use the transport expedited data transfer
  707.           service.
  708.  
  709.  
  710.  
  711. M. Rose & D. Cass                                              [Page 12]
  712.  
  713. RFC 1006                                                        May 1987
  714.  
  715.  
  716.           In order to achieve good performance, the default TPDU size is
  717.           65528 octets, instead of 128 octets.  In order to negotiate a
  718.           smaller (standard) TPDU size, the negotiation mechanism
  719.           specified in [ISO8073] is used (e.g., setting the desired bit
  720.           in the "TPDU Size" variable part).
  721.  
  722.           To perform an N-CONNECT.REQUEST action, the TS-peer performs
  723.           an active open to the desired IP address using TCP port 102.
  724.           When the TCP signals either success or failure, this results
  725.           in an N-CONNECT.INDICATION action.
  726.  
  727.           To await an N-CONNECT.INDICATION event, a server listens on
  728.           TCP port 102.  When a client successfully connects to this
  729.           port, the event occurs, and an implicit N-CONNECT.RESPONSE
  730.           action is performed.
  731.  
  732.               NOTE:      In most implementations, a single server will
  733.                          perpetually LISTEN on port 102, handing off
  734.                          connections as they are made
  735.  
  736. DATA TRANSFER
  737.  
  738.       The elements of procedure used during data transfer are identical
  739.       to those presented in [ISO8073], with one exception: expedited
  740.       data may be supported (if so negotiated during connection
  741.       establishment) by sending a modified ED TPDU (described below).
  742.       The TPDU is sent on the same TCP connection as all of the other
  743.       TPDUs. This method, while not faithful to the spirit of [ISO8072],
  744.       is true to the letter of the specification.
  745.  
  746.       To perform an N-DATA.REQUEST action, the TS-peer constructs the
  747.       desired TPKT and uses the TCP send data primitive.
  748.  
  749.       To trigger an N-DATA.INDICATION action, the TCP indicates that
  750.       data is ready and a TPKT is read using the TCP read data
  751.       primitive.
  752.  
  753. CONNECTION RELEASE
  754.  
  755.    To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes
  756.    the TCP connection.
  757.  
  758.    If the TCP informs the TS-peer that the connection has been closed or
  759.    has errored, this indicates an N-DISCONNECT.INDICATION event.
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770. M. Rose & D. Cass                                              [Page 13]
  771.  
  772. RFC 1006                                                        May 1987
  773.  
  774.  
  775. 6.  Packet Format
  776.  
  777.  
  778.       A fundamental difference between the TCP and the network service
  779.       expected by TP0 is that the TCP manages a continuous stream of
  780.       octets, with no explicit boundaries.  The TP0 expects information
  781.       to be sent and delivered in discrete objects termed network
  782.       service data units (NSDUs).  Although other classes of transport
  783.       may combine more than one TPDU including packet-header.  This
  784.       permits a maximum TPDU size of 65528 octets.  Based on the size of
  785.       the data transfer (DT) TPDU, this permits a maximum TSDU size of
  786.       65521 octets.
  787.  
  788.  
  789.       The format of the TPDU is defined in [ISO8073].  Note that only
  790.       TPDUs formatted for transport class 0 are exchanged (different
  791.       transport classes may use slightly different formats).  To support
  792.       expedited data, a non-standard TPDU, for expedited data is
  793.       permitted.  The format used for the ED TPDU is nearly identical to
  794.       the format for the normal data, DT, TPDU.  The only difference is
  795.       that the value used for the  TPDU's code is ED, not DT:
  796.  
  797.        0                   1                   2                   3
  798.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  799.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  800.       | header length | code  |credit |TPDU-NR and EOT|   user data   |
  801.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  802.       |      ...      |      ...      |      ...      |      ...      |
  803.       |      ...      |      ...      |      ...      |      ...      |
  804.       |      ...      |      ...      |      ...      |      ...      |
  805.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  806.  
  807.       After the credit field (which is always ZERO on output and ignored
  808.       on input), there is one additional field prior to the user data.
  809.  
  810.       TPDU-NR and EOT         8 bits
  811.  
  812.       Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end
  813.       of a XSDU (expedited TSDU).  All other bits should be ZERO on
  814.       output and ignored on input.
  815.  
  816.       Note that the TP specification limits the size of an expedited
  817.       transport service data unit (XSDU) to 16 octets.
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829. M. Rose & D. Cass                                              [Page 14]
  830.  
  831. RFC 1006                                                        May 1987
  832.  
  833.  
  834. 7.  Comments
  835.  
  836.  
  837.       Since the release of RFC983 in April of 1986, we have gained much
  838.       experience in using ISO transport services on top of the TCP.  In
  839.       September of 1986, we introduced the use of version 2 of the
  840.       protocol, based mostly on comments from the community.
  841.  
  842.       In January of 1987, we observed that the differences between
  843.       version 2 of the protocol and the actual transport class 0
  844.       definition were actually quite small.  In retrospect, this
  845.       realization took much longerr than it should have:  TP0 is is
  846.       meant to run over a reliable network service, e.g., X.25. The TCP
  847.       can be used to prrvide a service of this type, and, if no one
  848.       complains to loudly, one could state that this memo really just
  849.       describes a method for encapsulating TPO inside of TCP!
  850.  
  851.       The changes in going from version 1 of the protocol to version 2
  852.       and then to version 3 are all relatively small. Initially, in
  853.       describing version 1, we decided to use the TPDU formats from the
  854.       ISO transport protocol.  This naturally led to the evolution
  855.       described above.
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888. M. Rose & D. Cass                                              [Page 15]
  889.  
  890. RFC 1006                                                        May 1987
  891.  
  892.  
  893. 8. References
  894.  
  895.  
  896.    [GOSIP86]    The U.S. Government OSI User's Committee.
  897.                 "Government Open Systems Interconnection Procurement
  898.                 (GOSIP) Specification for Fiscal years 1987 and
  899.                 1988." (December, 1986) [draft status]
  900.  
  901.    [ISO8072]    ISO.
  902.                 "International Standard 8072.  Information Processing
  903.                 Systems -- Open Systems Interconnection: Transport
  904.                 Service Definition."
  905.                 (June, 1984)
  906.  
  907.    [ISO8073]    ISO.
  908.                 "International Standard 8073.  Information Processing
  909.                 Systems -- Open Systems Interconnection: Transport
  910.                 Protocol Specification."
  911.                 (June, 1984)
  912.  
  913.    [ISO8327]    ISO.
  914.                 "International Standard 8327.  Information Processing
  915.                 Systems -- Open Systems Interconnection: Session
  916.                 Protocol Specification."
  917.                 (June, 1984)
  918.  
  919.    [RFC791]     Internet Protocol.
  920.                 Request for Comments 791 (MILSTD 1777)
  921.                 (September, 1981)
  922.  
  923.    [RFC793]     Transmission Control Protocol.
  924.                 Request for Comments 793 (MILSTD 1778)
  925.                 (September, 1981)
  926.  
  927.    [RFC983]     ISO Transport Services on Top of the TCP.
  928.                 Request for Comments 983
  929.                 (April, 1986)
  930.  
  931.    [X.214]      CCITT.
  932.                 "Recommendation X.214.  Transport Service Definitions
  933.                 for Open Systems Interconnection (OSI) for CCITT
  934.                 Applications."
  935.                 (October, 1984)
  936.  
  937.    [X.224]      CCITT.
  938.                 "Recommendation X.224.  Transport Protocol
  939.                 Specification for Open Systems Interconnection (OSI)
  940.                 for CCITT Applications." (October, 1984)
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947. M. Rose & D. Cass                                              [Page 16]
  948.  
  949. RFC 1006                                                        May 1987
  950.  
  951.  
  952.    [X.225]      CCITT.
  953.                 "Recommendation X.225.  Session Protocol Specification
  954.                 for Open Systems Interconnection (OSI) for CCITT
  955.                 Applications."
  956.                 (October, 1984)
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006. M. Rose & D. Cass                                              [Page 17]
  1007.  
  1008.